This is misleading. The content of aria-label is read because there is no element with the id passed on aria-labelledby. It is not because Text has no id.

It is also important to note that the paragraph inside the content is also announced (although it shouldn't…). So this is a wrong implementation that we currently have and that we will need to fix. But until that happens I feel we should be clear about it, and adjust the documentation when the time comes.

Can you elaborate on the problem here, please? By "paragraph inside the content" you mean specifically the "Lorem ipsum dolor sit amet" text from the example? Or that the word "paragraph" as an element/role is being announced? Or what is the problem we need to fix?

The "Lorem ipsum dolor sit amet" is also announced because the tooltip is focused when it's open (it shouldn't, but that's an issue for another moment)

Isn't that the desired behavior to announce the tooltip content (at least I was under the impression it is, from reading the W3 materials)? Can you share some resources on this, please?

I have found some examples, and the content is read by a screen reader. Why the content shouldn't be announced by the reader?
https://dequeuniversity.com/library/aria/tooltip
https://inclusive-components.design/tooltips-toggletips/

The content of the tooltip must be announced, but not the way we are doing it, I suppose. Now with the migration to floating-ui things are a bit better, but in the past they were announced because we forced focus on the element, which should not be the case…

I am just saying that: if we have the content already being announced naturally (even if the implementation isn't perfect), what is the point of the aria-label? What should one put on the aria-label to be announced that is not announced by the content itself?

yeah, I know what you mean now. In the examples I have found before, aria-label should contain the name of the tooltip (like More info, etc..), but I get the point that aria-label is not needed (?) in this case when the tooltip content itself is read anyway - reference element includes readable text.

On the other side, I'm not sure if we will still get the Required ARIA attributes must be provided violation without having this attribute (and having labelledby, I have to check).

I get the point that aria-label is not needed (?) in this case when the tooltip content itself is read anyway.

Now I am confused by you 😅

From my understanding, the aria-label/aria-labelledby is not needed when reference element contains understandable text:

but is needed when we use the icon:

But maybe if the icon has accessible text already, aria-label on the Tooltip reference element is not needed at all?

yes, that's what I mean, sorry for the confusion. :D

Back to the first comment, I made some changes in the file.

Numbering in your examples is broken, both examples have 1., can you take a look at that, please?

I will post my comment here because it is connected to multiple places. I am super confused what is the purpose of the aria-label and aria-labelledby props in this component so I have a lot of questions 🙈

1. In the current implementation, TooltipWrapper has the role button, is that correct? Do you know why it has this role? I was trying to use screen reader and the "button" announce was always very confusing.

2. If there is a text provided as a children, there are no a11y violations - is it enough like this or should the aria-label (or aria-labelledby) be provided anyway, maybe with prefix "tooltip", that there is a tooltip? All of the violations with tooltip I saw were caused by the triggering (reference) element being icon - is this one of the examples where should the aria-label (or aria-labelledby) be provided or it should really be provided always, e.g. to avoid (double) announce of the content of reference element (I am kinda repeating myself here but you get what I am trying to ask 😅)? Should this be mentioned? The double announce happened to me on booking page with the self-transfer note, will we fix this?

3. Have you take a look at the aria-details property? Is it something we should also add here? If I understand correctly, it might be useful when there is more complex content inside the tooltip (e.g. lists) so the content of the element referenced by aria-details is not flattened to a string when presented to assistive technology users. I am asking as that seems to be a common usage of tooltips across our pages.

5. Two of three examples are the same, maybe one can be removed? I am not sure what should be the correct behavior with the children and what we need to fix, but if the aria-label (or aria-labelledby) are not provided and children is text, component is already accessible (or at least it doesn't violate anything) and these props don't need to be added. Should we mention that or is that just adding the expected things to the documentation (and what Daniel said is a bad precedent)? Maybe we could mention what should be passed to aria-label ideally or how should the element(s) being referenced by the aria-labelledby look like - should it sum up the content of the tooltip? Or just make introduction to tooltip content? Maybe the example can be real (as in the Seat component documentation where it mentions seat for a specific passenger) instead of just lorem ipsum text. Current examples also suggests that the aria-labelledby needs to be connected with the reference element but that't not true, no? Maybe we can use it with different element than children in the example?

1. I've found that the triggering component should be interactive - it was written on more websites, but I can't find it right now. I've found some sources talking about the <a> element, but AFAIK the role=button should be a general role for this. On the other side, we don't know what devs (will) put inside as a children component, so it might escalate other violation issues (?) -
   Example: in case there will be a <button> element as children, then we can get the Interactive controls must not be nested. cc @DSil

2. I think it was discussed above in the comment. ⏫

3. No, I haven't checked this aria-details property, tbh. It's hard to say if it makes sense to add this prop, on the other side, according to the articles about tooltips, the tooltip content should be simple, without any images/links/whatever, on the other side, we have various content in our tooltips across the Kiwi pages. 🤔
   I'm confused and lost about which approach should be better, tbh.

4. Yes, the two examples are the same, as I wanted to describe the further behavior. But I can take a look at it, and polish it, ofc.

Regarding point 1., I believe the role="button" is present because on mobile it is actually a clickable element, to trigger the MobileDialog. If that is the most correct approach…? I honestly don't know 😓 probably the role should be added only when it is indeed expecting a click. However, that would not prevent the raised question: what happens if one uses button as a tooltip trigger (should one even do it, ever?)

This table is broken, can you take a look at that, please?

I was thinking, maybe we can fix the stories a bit (applies to all 3 files) - since it's not recommended to use interactive elements inside the tooltip, we would remove the link from there. And we could also either remove the stories with tooltip on icon or add aria- attributes there as it makes more sense to have it there than here in Playground where it's already accessible with text. WDYT?

yes, I was also considering aligning the stories based on the updated tooltip and our observation.